IBIS Macromodel Task Group Meeting date: 01 August 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad noted that Walter had suggested the BIRD158.6 draft be given higher priority in this meeting. Arpad said he agreed, and we could discuss it today despite the fact that Radek had notified us that he could not attend. ------------- Review of ARs: - Bob Ross and Arpad to look into any BIRD191.1 interaction with [External ***]. - Done. A draft 2 of BIRD191.1 was mailed to the ATM reflector. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Randy: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD191.1 draft2: - Bob R.: [sharing draft2 of BIRD191.1] - Arpad: We found five instances of "at-pad", all of which were under [External Model], not [External Circuit]. - Bob R.: We changed the terminology from "at-pad" to "at-buffer terminal". - The "at-buffer terminal" location is identical to the [Model] buffer terminals. - Ambrish: I've always found this portion of the [External Model] text that you are changing to be confusing. - The text says, "If at-pad measurements are desired, the A_signal port would be named in the A_to_D line under port1." It also says, "If internal measurements are desired, the user-defined signal port would be named in the A_to_D line under port1." - Can we add a line to the spec to make it clear that both the A_signal and a user-defined "internal" node can be included in the Ports line at the same time? So the multi-lingual model could provide both ports and the model maker or user could select which one they want to use at [Model] creation time or run-time. - Since you're modifying this portion of the spec., perhaps we can add this clarification as well. - Arpad: Draft a sentence that you would like to include. - Bob and I weren't sure we would be touching this section until we reviewed it this past week. - Bob R.: I'll take what Ambrish submits and insert it. Then I'll submit that to the Open Forum as BIRD 191.1. BIRD158.6: - Arpad: [sharing 158.6 draft2 and the email thread with his comments] - We don't need to go over all of my comments. The one comment I'd like to discuss is the sentence where Radek and I seem to disagree the most: "Please note that the package data is added to the channel by the user using user’s own data or using some other vendor’s data." - First, a minor aesthetic issue with user-using-user's wording. - More importantly, I think this statement shouldn't be in the specification. - It is true that old style RLC matrices and other IBIS package models were so bad that people didn't use them. So users manually added different package models that they got by some other means. - But this statement is a description of what is currently the common practice, not the true intent of the spec. - The intent of the spec. is to provide packaging information, and now with BIRD189 we will have the ability to provide good packaging information. - I would oppose adding this sentence to the spec. - Walter: I agree. I would throw away that sentence. - We can come up with wording to explain how Ts4file_Boundary can be used by the EDA tool to determine if IBIS package model information should also be included or not. - BIRD158 was written well before BIRD189. - Why don't Arpad and I take the AR to reword this to make it compatible with BIRD189, and then we can see if what we come up with is acceptable to Radek? - Arpad: Okay. - Bob R.: Okay. I have two comments: - We define a "pad" in Ts4file_Boundary, but we don't really show what that is. - Is that a physical pad or a pad related to something else? - It may not relate to BIRD189. - I'm still puzzled as to why these parameters are all Usage Dep, but not Out. - Every other Reserved parameter that can be Usage Dep can also Usage Out. - What is special about these? - I think they should be Usage Info, Dep, or Out. - Fangyi/Mike L.: Usage Dep parameters are resolved before Init() or GetWave(). BIRD166.3: - Walter [sharing his "BIRD166 - BIRD190 Summary" presentation] - [sharing slide 8 to start] - There are two redriver flows in the spec., statistical flow and time-domain flow. - BIRD166.3 is now limited to the statistical flow. - In the current IBIS 6.1 redriver statistical flow, the IR input to Rx2 Init() does not include the upstream channel effects. - With BIRD166.3, the upstream channel IR is convolved with the downstream channel information prior to calling Rx2 Init(). - Does anyone object to this change to the statistical flow for redrivers? - Fangyi: I do. - Walter: Why? - Fangyi: First, with this change the IR matrix grows exponentially when you have more redrivers in the channel. Without the self IR of each section, one can't form IRs of all the possible crosstalk paths by combining the self IRs of different sections. So IRs of all cross- talk paths must be included in the IR matrix, causing the matrix size to grow exponentially with the number of channels and redrivers in the system. - Second, when you have a feedback loop, this method won't work because you can call Init() only once. - Walter: What feedback loop are you talking about? - Fangyi: Any time you have a network you can always have a feedback loop. - Arpad: How is it related to the redrivers? Are you saying a chain of redrivers goes back to the original driver? - Fangyi: The signal can go through a feedback loop and experience the equalization of a redriver a second time. It doesn't need a redriver ring to form a feedback loop. In general, a feedback loop can exist in any network that has multiple channels and multiple redrivers. - Mike L.: Are you saying this would be handled correctly in the current spec.? - Fangyi: Yes. In the current spec you have the self IR of each section of the channel. - With the self IR of each section, the tool can represent any path it wants using the individual self IRs. - With BIRD166.3 you only have the cumulative IR at each redriver, and you don't have the self IRs of the individual sections. - So a loop can't be handled. You can only call Init() once, so you can't have a signal experience a redriver twice. - Crosstalk is a problem without the self IRs. If the tool doesn't have the self IRs, then it has to put the crosstalk IRs that couple in at each redriver into all the subsequent redrivers' IR matrices. So the IR matrix grows as you go down the chain. - Ambrish: This (BIRD166.3) will make the time domain Init() flow different from the statistical Init() flow. - Walter: I think the same change belongs in the time domain flow, but I took the time domain flow change out of BIRD166.3 because you objected. - [sharing "Alternative Redriver Time Domain Flow" slide 10] - Current time domain flow has this step 6. - Your BIRD190 would add this new note. I have no problem with this note. It identifies and highlights the problem with the current flow. - I would like to add this alternative step 6 (that says the convolution may be done prior to calling Rx2 Init()). - Your option relies on running the Rx2 Init() in manual configuration mode. - Both options can get the same answer eventually, but my proposed flow would arrive at it much more quickly. - Ambrish: The main assumption in this is that you're modeling optimization in Init(). - That's a huge assumption (for time domain flow) about what all the upstream models are doing (Init_Returns_Impulse must be true for all of them), and you can't really mandate that in the spec. - Walter: The redriver section already refers back to the single channel flow, where your optimization warning already exists. - The user will know if all of the models have Init_Returns_Impulse=true, and in that case all the information would be available to Rx2 Init() to optimize itself (with BIRD166.3 flow). - Walter: I think we should drop this whole discussion and table BIRD166 and BIRD190 and not consider them for IBIS 7.0. - If Ambrish will allow BIRD190 to be tabled, I will table BIRD166.3 after introducing it at the Open Forum. - We table both and let the market decide what flow is correct. - [sharing "Bob Miller's Comments" slide 5]. - Bob Miller is a model maker and finds it "hugely disappointing" that BIRD190 would codify this limitation. - Four years ago SiSoft published the problem with the existing 6.1 flow, and we documented our own flow. - Ambrish: The main problem in what Bob M. is asking for is that he's doing optimization in Init() and has that huge assumption about what upstream models are doing. - Walter: That warning about optimizing in Init() is true for all Rx models. - Ambrish: What Bob wants, he could get by having the user enter preset tap coefficients manually. - Walter: I know you believe in adaptation in GetWave(). - If you look at modern Rx models, e.g. 802.3bj, they expect 14 tap DFEs. - They expect hardware to adapt in perhaps 1 second. At 25GHz, that gives them 25e9 UIs to work with. - Typically GetWave() simulations in EDA tools are on the order of 1e6 UI per minute. You can take 25,000 minutes to do adaptation. - Many companies are committed to a statistical flow. - Michael Mirmak has said Intel is committed to a statistical flow. - Other IC vendors are committed to a statistical flow. - Ambrish: I have models from Intel that provide a GetWave(). - Walter: They may generate models with GetWave(), but internally they are committed to supporting statistical flow. - Ambrish: How do you expect the flow to work if it assumes all models have Init_Returns_Impulse=true? - Walter: When we have a GetWave() only model, we create a proxy Init(). - When we have an Init() only model, we make a proxy GetWave(). - We presented Mike Steinberger's paper on this subject at DesignCon. - We would prefer all models were Dual models, and many of our customers make their vendors provide Dual models. - We think it's silly to give out an Init only model. If you have an Init only model you can easily generate a GetWave() function. David Banas provides open source code to do it. - Optimizing a 14 tap DFE in Init() is trivial. If you have AGC and CTLE it adds complications, but we still have ways to do it. - Ambrish: We can't force model makers to produce dual models. - Fangyi: We can't put something in the spec. that is mathematically wrong. Your change would break the time domain flow. - Arpad: We have been round and round on this for months. - I don't think we are getting any closer to an agreement. - Motion to table BIRD190 and BIRD166. - Walter: Second. [none opposed] - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Mike L. to post BIRD 191.1 draft 2 to the ATM archives. AR: Ambrish to draft a proposed sentence to add to the [External Model] section as part of BIRD191.1 and send it to Bob R. AR: Bob R. to create BIRD 191.1 draft 3 with Ambrish's sentence and submit it to the Open Forum as BIRD191.1. AR: Walter and Arpad to modify the current BIRD158.6 draft to make it compatible with BIRD189. AR: Mike L. to post Walter's "BIRD166 - BIRD190 Summary" to the ATM archives. ------------- Next meeting: 08 August 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives